One problem in the software field is the generation and support of numerous open-source distributions (e.g., different distributions of an open-source operating system (OS)) based on a common base of components and practices, but including many differences among the distributions. While many people are currently able to build such an OS kernel and upgrade a system with the new kernel, the ability to accomplish such builds in connection with a complete distribution represents a harder problem.
A complete distribution is much more than a kernel, and has several components including: an installer, or possibly several installers to accommodate multiple targets; development tools (for embedded systems, these are likely to include cross development tools from a selection of platforms); a root file system including all the software outside the kernel that is necessary to boot and operate the system (a set of shared library components would normally be included a part of the root file system); and documentation. These components all interact. In many cases, components require special versions of other components in order to function. Components may even require non-standard “patches” applied to other components to work together. Harmonizing hundreds of components is a combinatorial problem. Many combinations simply will not work with any set of versions and patches. Thus, assembly of a working distribution is a hard problem that gets rapidly harder as components are added to the distribution.
The distinction between a complete distribution (e.g., a commercial-quality distribution) and a modified kernel provides one motivation for the present invention. Consider a company that has created a new single-board computer (for instance) and wants to support Linux on that platform. The company can contract for the software with a company that supplies a Linux distribution, but that is a limited resource and consequently the process is probably slow and expensive. The company can also download the Linux sources and do the port themselves. That approach, however, gives the company only a working kernel, not a complete distribution. Even if the company has created a working distribution, a commercial Linux vendor is unlikely to adopt the distribution and provide support and maintenance because the “wild” board-support package (BSP) is likely to differ from the distribution the vendor provides. Since a “wild” BSP is, by definition, created outside the commercial Linux vendor's control there is no practical way to be certain that the distribution meets the vendor's standards. The current usual practice is for the hardware vendor to do a Linux port to their computer, and then pass that port to a company that builds a Linux distribution. That company uses the code from the hardware vendor as a guide and repeats much of the hardware vendor's work as the Linux vendor does a port of their distribution to the new platform. For the Linux vendor, this is faster than doing the port from scratch, but it is still time-consuming and expensive. The alternatives for the hardware vendor are to supply and support a Linux distribution (an expensive, long-term commitment), or to provide the raw kernel to their customers and leave them with a generally non-professional operating system package.
The prior art operates on the model that people either contribute to one of the broadly-supported distributions, or they take a standard distribution, modify it independently, and depart from the standard. For most of the prior art Linux distributions, departing from the distribution is relatively easy because the “machinery” for building the distribution is publicly available, but the new distribution is now an independent entity that needs an ongoing support effort. Contributing to the standard distribution is either the job of the “owner” of the distribution, or it has (necessarily) a careful community-based review process, and changes might not be accepted into the distribution even though someone needs those changes for their system.
In order to provide a system that lets users easily build a custom distribution, then easily pass that distribution back to an organization that can easily assume ongoing responsibility for it, three distinct problems need to be solved: (1) easy assembly of a certified distribution containing standard components and possibly special components; (2) easy transition of any work back to the shared base; and (3) scalable support for all distributions built with the system. Prior art systems solve the scalable support problem by strictly limiting the number of supported distributions/products. That makes problem three trivial, but totally fails to address problem one. Prior art systems solve problem two with a social/code review process on submission to the distribution. That has proven efficient at maintaining high quality, but it is labor intensive and offers no path for adding code to the distribution that is not widely supported by the community. What is needed is a single system that solves all three of the problems, and thereby permits users to easily build a custom distribution, and then pass that distribution back to an organization that can easily assume ongoing responsibility for it.